Reflection as a Tool to Debug Objects

International audienceIn this paper, we share our experience with using reflection as a systematic tool to build advanced debuggers. We illustrate the usage and combination of reflection techniques for the implementation of object-centric debugging. Objectcentric debugging is a technique for object-oriented systems that scopes debugging operations to specific objects. The implementation of this technique is not straightforward, as there are, to the best of our knowledge, no description in the literature about how to build such debugger. We describe an implementation of object-centric breakpoints. We built these breakpoints with Pharo, a highly reflective system, based on the combination of different classical reflection techniques: proxy, anonymous subclasses, and sub-method partial behavioral reflection. Because this implementation is based on common reflective techniques, it is applicable to other reflective languages and systems for which a set of identified primitives are available

First Infrastructure and Experimentation in Echo-debugging: Preprint from IWST20: International Workshop on Smalltalk Technologies

As applications get developed, bugs inevitably get introduced. Often, it is unclear why a given code change introduced a given bug. To find this causal relation and more effectively debug, developers can leverage the existence of a previous version of the code, without the bug. But traditional debug-ging tools are not designed for this type of work, making this operation tedious. In this article, we propose as exploratory work the echo-debugger, a tool to debug two different executions in parallel, and the Convergence Divergence Mapping (CDM) algorithm to locate all the control-flow divergences and convergences of these executions. In this exploratory work, we present the architecture of the tool and a scenario to solve a non trivial bug

Tool demo: fine-grained run-time reflection in Python with Reflectivipy

Reflectivipy is a Python implementation of sub-method, partial behavioral reflection (SPBR). SPBR provides selective reflection operations applicable to sub-elements of methods (e.g., sub-expressions). SPBR helps in run-time code instrumentation with various application, from advanced debugging to hot patching of running programs. In this tool paper, we briefly describe SPBR and its Reflectivipy API and implementation. We illustrate Reflectivipy through two examples: first we build and demonstrate a basic object-centric debugger and describe how SPBR favors its implementation and second, we hot patch a running REST server. CCS Concepts: • Software and its engineering → Maintaining software; Object oriented development; Development frameworks and environments; Object oriented frameworks; Software maintenance tools; Software notations and tools

Sub-method, partial behavioral reflection with Reflectivity: Looking back on 10 years of use

Context. Refining or altering existing behavior is the daily work of every developer, but that cannot be always anticipated, and software sometimes cannot be stopped. In such cases, unanticipated adaptation of running systems is of interest for many scenarios, ranging from functional upgrades to on-the-fly debugging or monitoring of critical applications. Inquiry. A way of altering software at run time is using behavioral reflection, which is particularly well-suited for unanticipated adaptation of real-world systems. Partial behavioral reflection is not a new idea, and for years many efforts have been made to propose a practical way of expressing it. All these efforts resulted in practical solutions, but which introduced a semantic gap between the code that requires adaptation and the expression of the partial behavior. For example, in Aspect-Oriented Programming, a pointcut description is expressed in another language, which introduces a new distance between the behavior expression (the Advice) and the source code in itself. Approach. Ten years ago, the idea of closing the gap between the code and the expression of the partial behavior led to the implementation of the Reflectivity framework. Using Reflectivity, developers annotate Abstract Syntax Tree (AST) nodes with meta-behavior which is taken into account by the compiler to produce behavioral variations. In this paper, we present Reflectivity, its API, its implementation and its usage in Pharo. We reflect on ten years of use of Reflectivity, and show how it has been used as a basic building block of many innovative ideas. Knowledge. Reflectivity brings a practical way of working at the AST level, which is a high-level representation of the source code manipulated by software developers. It enables a powerful way of dynamically add and modify behavior. Reflectivity is also a flexible mean to bridge the gap between the expression of the meta-behavior and the source code. This ability to apply unanticipated adaptation and to provide behavioral reflection led to many experiments and projects during this last decade by external users. Existing work use Reflectivity to implement reflective libraries or languages extensions, featherweight code instrumentation, dynamic software update, debugging tools and visualization and software analysis tools. Grounding. Reflectivity is actively used in research projects. During the past ten years, it served as a support, either for implementation or as a fundamental base, for many research work including PhD theses, conference, journal and workshop papers. Reflectivity is now an important library of the Pharo language, and is integrated at the heart of the platform. Importance. Reflectivity exposes powerful abstractions to deal with partial behavioral adaptation, while providing a mature framework for unanticipated, non-intrusive and partial behavioral reflection based on AST annotation. Furthermore, even if Reflectivity found its home inside Pharo, it is not a pure Smalltalk-oriented solution. As validation over the practical use of Reflectivity in dynamic object-oriented languages, the API has been ported to Python. Finally, the AST annotation feature of Reflectivity opens new experimentation opportunities about the control that developers could gain on the behavior of their own software

Reflectivipy: building python debuggers with sub-method, partial behavioral reflection

International audienceBuilding debugging tools is hard and requires powerful tools and libraries. In object-oriented technologies, it is common to use fine-grained reflection to implement debuggers. In this tool presentation, we describe how partial behavioral reflection applied to sub-elements of a method helps in the implementation of advanced debugger features. As an example, we present an implementation of object-centric breakpoints in python

Handling Error-Handling Errors: dealing with debugger bugs in Pharo: Preprint from IWST20: International Workshop on Smalltalk Technologies

In Pharo, errors happening during the opening of a debugger provoke error-handling errors. The Pharo system then drops into a rudimentary emergency evaluator, which provides extremely limited debugging features. This is a real problem while developing debuggers, when debuggers are more subject to bugs. In addition, the Pharo debugging infrastructure exposes an heterogeneous, obscure interface with various usages and users. Therefore, trying to extend this infrastructure to cope with debuggers bugs is tedious. In this technical paper, we present Oups, an improved debugger infrastructure for Pharo. Oups provides a unified interface as a single entry point to request the opening of debuggers. Upon a debugger opening request, Oups uses interchangeable debugger opening strategies to select which debugger to open. We implemented a strategy that allows for the debugging of a failing debugger by other debuggers instead of the emergency evaluator. Oups improves the resilience of the Pharo system for specific cases of error-handling errors that we analyse

New Generation Debuggers: Défis du GDRGPL 2020

Debugging is a painful and costly practice, due to the nature of bugs, of the debugged programs, or to tools limitations. We describe several difficulties of debugging that present scientific challenges (i.e., we don't know how to do it) or technological challenges (i.e., we can't do it). We believe that addressing these challenges will lead to new generation de-buggers that will significantly ease and lower the cost of debugging

Time-Traveling Debugging Queries: Faster Program Exploration

International audienceEfficiently debugging a program requires program comprehension. To acquire it, developers explore the program execution, a task often performed using interactive debuggers. Unfortunately, exploring a program execution through standard interactive debuggers is a tedious and costly task. In this paper, we propose Time-Traveling Queries (TTQs) to ease program exploration. TTQs is a mechanism that automatically explores program executions to collect execution data. This data is used to time-travel through execution states, facilitating the exploration of program executions. We built a set of key TTQs based on typical questions developers ask when trying to understand programs. We conducted a user study with 34 participants to evaluate the impact of our queries on program comprehension activities. Results show that, compared to traditional debugging tools, TTQs significantly improve developers' precision, while reducing required time and efforts when performing program comprehension tasks